In 2012 I wrote:
While reading Jared Smith’s excellent article WCAG Next I was drawn to the following statement “next to impossible to evaluate” in reference to the checking of WCAG 2.0 success criterion 4.1.1 Parsing.
In 2015 I wrote WCAG 2.0 Parsing Criterion is a PITA which discusses the ins and outs of the Parsing criterion.
In 2019 we have WCAG 2.1, with no change to the parsing criterion.
In 2012 I wrote: and this holds true in 2019 (as far as I know).
It is true (as far as I know) that there is no currently available dedicated service or software for checking 4.1.1 Parsing. What I do and advise clients to do is use the W3C validation service to check their code as the checks required for parsing criterion conformance are a subset of the checks that are made when validating HTML code.
Identifying relevant errors and warnings
A problem with using a standard HTML validator to check for this subset is that many other conformance errors and warnings are also reported and while these may or may not be important to fix, they are not a requirement within the scope of the success criterion. What I have been doing is checking pages against the HTML5 doctype as this minimizes the occurance of errors and warnings that are unrelated to parsing, but still a page can contain many non parsing errors, making it difficult to identify the relevant results.
I have also had discussions with Mike Smith (W3C Nu Markup Validation Service) and Henri Sivonen (Validator.nu) about providing a method to filter conformance results to display only parsing issues. There are apperently some design reasons why this would be difficult (not impossible) from a backend code perspective, so I thought a reasonable place to start would be with a client side script that filtered the display of results from a validator.
Parsing error bookmarklet
The WCAG parsing only bookmarklet is an experimental script that loops through the results displayed when using W3C Nu Markup Validation Service. It looks for certain text strings in the results output and if it does not find them in the text for a particular result it hides that result using CSS display:none.
Check results other than the following are filtered:
- Elements have complete start and end tags
- Elements are nested according to their specifications
- Elements do not contain duplicate attributes
- Any IDs are unique
- Unquoted attributes (under certain circumstances)
- Duplicate attributes
- Mismatched quotes on attributes
- Attributes not space seperated
- Mismatched element start and end tags
- malformed attributes
See the Pen
WCAG Parsing Bookmarklet by steve faulkner (@stevef)
on CodePen.
WARNING
This is an experiment only, due to various constraints the method used to filter the results is not the most robust as it relies upon text string matching.
Note: this experiment would not have been possible without the help of my friends and colleagues Hans Hillen, Gez Lemon and Dennis Lembrée who although they thought the method used was crappy, helped me anyway.
Comments
An excellent resource Steve. My “next to impossible to evaluate” claim was overly broad – and this tool certainly proves that to be the case. What IS “next to impossible to evaluate” is whether those parsing errors make any difference for accessibility. As I noted in my article, I’m not aware of any such errors that affect assistive technology that are not already addressed by other guidelines.
In short, while valid code is always an excellent idea, I don’t see how the 4.1.1 Parsing requirement does anything to aid accessibility.
First off – siteSifter does validation as part of both the WCAG 1 and 2 baselines, as well as partial validation (the “required checks” above) in a client-specific set of tests. It is somewhat heuristic the whole thing, of course, but it is quite possible. Note that this relate to HTML validation – HTML5 is a different kettle of fish.
Secondly, I’d claim that validation DOES aid accessibility, as it’ll remove such bugs as unclosed elements, or more precisely incorrectly closed ones, which can make certain things very difficult. I’m sure we’ve all run across pages that are one, gigantic, hyperlink because an A got left out somewhere … it is, of course, not a panacea.
Hi Jared,
I have found the odd nesting error that has affected a screen readers ability to convey table information correctly and having multiple form controls with the same id values is definielty a potential issue, so cannot agree with you completely on this one.
Inspiration bit of sideways thinking Steve, will follow this with interest.
My thoughts on the parsing debate: Clean code will not harm accessibility, bad code might. Why take the risk? In addition, clean code is quicker to load and easier for search engines to read. The outcome: accessible, speedy and well ranked.
Steve –
If a screen reader is unable to get table information or if form controls are not properly associated, these would be failures of other success criteria. My point still stands – I can think of no parsing error that BY ITSELF causes accessibility issues that are not covered elsewhere in WCAG.
Again, I’m not arguing against validation, I just don’t think it should be an accessibility conformance requirement.
Hi Jared,
I still think it’s useful to require the checking of such errors in the code.
When performing user accessibility testing, I have often wondered if criteria 4.1.1 should be flagged, but have concluded like Jared that it is not really an accessibility issue. I assume it will be flagged by automated tool testing, and since it comes under the Robust category, it is “Value Added” and simply good coding. However, it should remain as a criteria check, as it will reduce manual user testing accessibility errors considerably.
Hello Steve,
As a screen reader user & accessibility consultant I feel that SC 4.1.1 complicate things for anyone who want to comply to the WCAG 2.1… most of what SC 4.1.1 doesn’t affect people with disability other than unique id’s which needs to be taken care off. Other than that particular issues like Elements have complete start and end tags, elements are nested according to their specifications & elements do not contain duplicate attributes doesn’t seem to affect… I haven’t seen any example till date where they created major accessibility issues. I may be wrong & would like to hear your thoughts.
Hi Steve
My concern is that accessibility budgets sometimes can get stretched fixing errors that doesn’t cause accessibility problems, such as duplicate ids that aren’t on interactive components.
This original article is from 2012 and browsers have come a long way since then. Perhaps its time to revisit removing 4.1.1.